-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug fixes for max net metering benefit, multi-period and multi-tier demand charges #401
Conversation
addresses #386 |
Checked and confirmed that these fixes address previous issues in results from these posts: |
@zolanaj Done reviewing with just two remaining comments! |
Regarding #297 , documenting that currently the below (a) results in (a)
(b)
|
…ectric_tariff.monthly_demand_tier_limits
@adfarth Ready for you to check again! There are more tests in the new set and the limits are now indexed on month (or ratchet). |
|
||
for tier in range(1, stop=n_energy_tiers) | ||
|
||
for month in range(1, stop=12) | ||
period = Int(d["energyweekdayschedule"][month][1] + 1) | ||
for tier in range(1, stop=n_energy_tiers) | ||
# tiered energy schedules are assumed to be consistent for each month (i.e., the first hour can represent all 24 hours of the schedule). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this means that if you have a rate with multiple periods within a month, and the tier maxes (kWh) vary between those periods, REopt will overwrite the tier max values for all periods that are not the hour 1 period, using hour 1 period maxes.
For example, period 1 here would be assumed to have a 1st tier max of 88 in May-Sept, and a 1st tier max of 100 in Nov (given the resulting energy_tier_limits matrix shown below); is that a correct interpretation?
energy_tier_limits_kwh: [88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 100.0 1.0e10; 88.0 1.0e10]
Is it accurate to say this is still not fully capturing the intended rate, but is one step better than what we did before, which was assume that all periods[tiers] had the same max limits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this means that if you have a rate with multiple periods within a month, and the tier maxes (kWh) vary between those periods, REopt will overwrite the tier max values for all periods that are not the hour 1 period, using hour 1 period maxes.
For example, period 1 here would be assumed to have a 1st tier max of 88 in May-Sept, and a 1st tier max of 100 in Nov (given the resulting energy_tier_limits matrix shown below); is that a correct interpretation?
energy_tier_limits_kwh: [88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 100.0 1.0e10; 88.0 1.0e10]
Is it accurate to say this is still not fully capturing the intended rate, but is one step better than what we did before, which was assume that all periods[tiers] had the same max limits?
That's correct if we are talking about monthly rates and limits, but the time-of-use "ratchets" allow for custom definition of periods and so this setup likely assigns a separate "ratchet" that consists of thirty hourly periods from 12-1am and another for all the other hours in November, each of which has its own separate tiers and limits. I'd expect to see 18 time-of-use periods in this setup, each of which has two tiers.
So, to that end: is the above matrix what's actually produced when you insert this custom output or do you get the 2x18 matrix? One thing I did not touch as part of this PR is the logic for when custom time-of-use vs. monthly tiers are generated. We can revisit that, but it's likely best reserved for an issue at this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
piggybacking on this comment: what I said above applies to demand charges but not energy rates, so this is a missing feature as compared to everything that the URDB rate builder allows for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zolanaj Approving with just a few comments requesting updates to help text and a few questions to help me understand the changes. Thanks for making these improvements and fixes!
@zolanaj Adding one more thing that we can definitely punt to another PR unless you think it makes sense to address here: It looks like the |
Great catch! I'm adding an issue here: #416 |
Thanks for the thorough review @adfarth! after making some edits in response to this last round I will merge once tests are confirmed to pass. |
bug fixes for max net metering benefit, multi-period and multi-tier demand charges
Fixed